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Executive  Summary 


This  research  addresses  the  problem  of  how  to  (1 )  value  architectural  options 
that  deliver  capabilities  to  the  warfighter  not  inherently  measured  in  dollar  values  and 
(2)  conduct  a  trade  study  of  architectural  options,  the  option’s  cost,  and  the  option’s 
risk  to  support  the  affordability  mandate  for  a  more  effective  and  efficient  acquisition 
decision-making  process.  The  research  models  acquisition  as  a  sequential  decision 
process  with  an  options  framework  but  with  two  significant  distinctions:  First,  it 
identifies  and  values  system  architectural  options  available  in  the  system  design, 
and  not  options  on  the  project,  and  second,  it  measures  capabilities  in  terms  of 
mission  effectiveness  compatible  with  how  defense  managers  think.  Architectural 
options  provide  flexibility  to  deal  with  technical  and  operational  uncertainty.  The 
research  contributes  to  the  performance  of  trade  studies  in  acquisition  through  the 
definition  of  architectural  options  in  terms  consistent  with  defense  acquisition 
(capabilities  and  not  cash  flows)  and  a  theory  for  how  program  managers  can  value 
the  capabilities  those  options  provide.  The  research  is  intended  to  support  the 
evolutionary  acquisition  of  system  capabilities.  As  RADM  Rowden  (2014),  the 
director  of  Surface  Warfare  stated. 

We  cannot  afford  to  build  ships  that  are  retired  because  they  have 
been  outpaced  by  the  threat;  rather,  they  will  need  to  be  retired 
because  they  have  reached  the  end  of  their  service  life.  Defined 
interfaces  and  modular  designs  will  treat  capability  as  a  commodity, 
enabling  continuous  modernization  to  stay  one  step  ahead  of  the 
threat.  These  “designed-in”  features  will  dramatically  lower  the 
complexity  of  modernizing  ships,  reducing  the  time  spent  in  overhauls, 
increasing  operational  availability,  and  reducing  total  ownership  cost. 

Keywords:  System  architecture,  capability-based  analysis,  real  options, 
systems  engineering. 
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Valuation  of  Capabilities  and  System 
Architectural  options  to  Meet  Affordabiiity 

Requirement 


Introduction 

The  U.S.  Department  of  Defense  (DoD)  acquires  systems  to  deliver 
capabilities  needed  by  the  warfighter.  Acquisition  of  a  system  starts  with  defining 
capability  gaps  and  covers  the  system  development  life  cycle  from  initial 
conceptualization  to  system  production  and  delivery.  Several  challenges  continue  to 
plague  the  acquisition  process  of  new  systems;  the  adoption  of  a  real  options 
framework  to  evaluate  architecture  design  might  help  address  these  challenges.  In 
very  complex  systems  for  dynamic  military  environments,  it  is  inevitable  that  user 
needs  and  operational  requirements  will  change.  While  change  is  foreseeable,  the 
exact  nature  of  the  change  is  not.  The  real  options  framework  is  intended  to  value 
and  defend  the  inclusion  of  flexibility  in  system  architectures  to  deal  with  uncertainty 
in  technology  and  operational  needs  and  ensure  that  the  system  delivers  value  to 
stakeholders  over  the  span  of  its  intended  life  cycle.  Flexible  system  architectures 
hold  out  the  possibility  of  systems  that  can  evolve  and  adapt  to  changing  operational 
and  technical  needs  in  order  to  achieve  affordable  programs  over  the  long  term.  This 
research  report  describes  a  framework  for  applying  real  options  to  value  flexibility  in 
system  architectures. 

Acquisition  Background 

A  capability  is  a  system’s  enduring  ability  to  generate  a  desired  operational 
outcome  or  effect  in  the  context  of  its  environment.  The  U.S.  DoD  uses  a  capability- 
driven  process  to  determine  capabilities  needed  by  the  warfighter.  The  capability- 
based  analysis  (CBA)  is  governed  by  the  Joint  Capability  Integration  Development 
System  (JCIDS).  The  intent  of  a  capability-based  acquisition  model  is  to  remain 
solution  neutral  to  remove  any  bias  toward  a  particular  system  or  technology.  CBA 
focuses  on  what  the  warfighter  needs  rather  than  how  the  needs  can  be  delivered. 
Moreover,  it  emphasizes  the  combination  of  materiel  or  system  solutions  with  non¬ 
materiel  solutions  achieved  through  what  is  called  doctrine,  organization,  training, 
leadership  and  education,  personnel,  and  facilities  (DOT  LPF)  changes.  There  are 
challenges  with  the  CBA  approach,  among  them  the  difficulty  of  envisioning  abstract 
capabilities  without  also  considering  how  those  capabilities  are  delivered. 

Under  diminishing  budgets  yet  a  constant  (or  even  a  growing)  threat 
environment,  the  DoD  must  be  able  to  acquire  and  deliver  capabilities  more 
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affordably.  The  Defense  Acquisition  System  develops  and  fields  systems  to  meet  the 
requirements  defined  by  JCIDS.  In  2010,  Dr.  Carter,  while  serving  as  under 
secretary  of  defense  for  acquisition,  technology,  and  logistics  (USD[AT&L]),  issued  a 
memo  for  the  Better  Buying  Power  (BBP)  initiative  to  improve  the  efficiency  of  the 
acquisition  process.  Part  of  the  BBP  initiative  is  to  mandate  affordability  as  a 
requirement  when  considering  systems  to  acquire.  Affordability  is  intended  to  ensure 
program  success  by  balancing  system  performance,  total  ownership  cost,  and 
schedule  while  also  considering  the  DoD’s  long-range  investment  plans.  Two 
additional  USD(AT&L)  memos  further  addressed  the  incorporation  of  affordability 
considerations  into  the  Defense  Acquisition  System.  The  affordability  target  is 
treated  by  the  program  manager  as  a  key  performance  parameter  that  is  used  in 
pre-Milestone  B  decision-making  and  systems  engineering  trade-off  analysis.  New 
programs  need  to  produce  an  affordability  analysis  pre-Milestone  A,  including  an 
affordability  element  in  the  analysis  of  alternatives  and  a  systems  engineering  trade¬ 
off  analysis  pre-Milestone  B.  The  trade-off  analysis  should  show  how  the  program 
costs  vary  against  the  major  design  parameters  as  well  as  the  projected  schedule. 
The  BPP  initiative  also  calls  on  program  managers  to  pay  attention  to  spiral 
upgrades  because  it  is  apparent  that  systems  will  have  to  be  upgraded  in  order  to 
continue  providing  value  during  anticipated  long  operational  lives. 

Instituting  the  intent  of  the  memo  requires  both  a  cultural  shift  in  how  the  DoD 
views  system  architecture  and  programs  as  well  as  the  tools,  methods,  and 
processes  to  support  affordability  analysis.  The  perspective  of  this  research  is  that 
the  acquisition  system  is  a  sociotechnical  system,  or  an  enterprise  system  consisting 
of  people,  processes,  and  data  that  are  used  to  acquire  systems  that  are  the  output 
of  the  acquisition  process.  Letting  the  sociotechnical  perspective  inform  the  research 
approach,  this  paper  emphasizes  that  transforming  how  the  DoD  conducts 
acquisition  to  make  it  more  efficient  requires  not  just  tools  but  also  cultural  change.  I 
believe  that  the  foremost  needed  change  in  perspective  is  for  the  DoD  to  start 
thinking  about  systems  not  as  a  point  solution  to  a  well-defined  set  of  requirements 
but  as  a  set  of  architectural  options  that  will  allow  the  system  to  adapt  and  change  to 
shifting  capability  needs  and  threats  over  its  lifetime.  Koenig,  Nalchajian,  and 
Hootman  (2009),  from  Naval  Sea  Systems  Command,  echoed  this  change  in 
perspective  when  they  remarked  that  conventional  decision  analysis  methods  are 
oriented  to  decision-making  under  certainty,  which  is  inappropriate  for  the  acquisition 
of  ships  that  require  the  evaluation  of  large,  risky  expenditures  for  a  long-lived 
investment.  The  defense  acquisition  process  demonstrates  and  acknowledges  that 
systems  must  change  in  the  increasingly  planned  use  of  system  spiral  upgrades. 
However,  the  success  of  spiral  upgrades  is  premised  on  the  specification  of  a 
system  architecture  that  will  accommodate  these  changes.  Designing  such  a  system 
architecture  is  fraught  with  difficulty.  To  illustrate  some  of  the  challenges,  consider 
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the  U.S.  Army’s  lightweight  counter  mortar  radar  system  (LCMR),  which  is  part  of  a 
the  Counter-Rocket,  Artillery,  and  Mortar  (C-RAM)  system  of  systems.  In  the  first 
spiral  of  the  development  and  acquisition  process,  there  was  a  trade-off  decision  to 
have  a  smaller  hardware  unit  to  save  on  weight  and  then  make  up  for  the  smaller 
hardware’s  lower  signal-to-noise  ratio  (SNR)  performance  with  software  that  could 
provide  a  higher  virtual  SNR  through  a  sampling  algorithm.  However,  in  the  second 
spiral  iteration  to  acquire  additional  capabilities  for  when  the  LCMR  was  integrated 
with  the  C-RAM,  it  was  found  that  the  trade-off  decision  to  compensate  for  the  lower 
hardware  SNR  with  software  in  the  first  spiral  led  to  an  unacceptable  time  delay.  As 
a  result,  a  costly  redesign  of  the  LCMR  software  ensued  to  reduce  the  time  delay. 
This  very  brief  description  of  a  complex  acquisition  program  highlights  the  difficulty  in 
making  decisions  because  of  the  sequencing  of  decisions,  the  uncertainty  involved, 
and  the  constantly  evolving  needs  of  our  military.  What  was  missing  in  this  case  was 
the  perspective  to  define  and  value  capabilities  over  the  entire  life  of  the  system  and 
feedback  those  valuations  into  a  system  architecture  that  can  be  affordably  adapted 
to  deliver  those  capabilities. 

Acquisition  Issues 

This  section  reviews  five  of  the  main  issues  that  architectural  options  can  help 
address  in  DoD  acquisition. 

Complexity 

The  DoD  tends  to  acquire  highly  complex  technological  systems.  The 
complexity  is  manifested  as  technology  risk  in  the  system  and  as  long 
development  times  to  iterate  through  design-test-build  cycles.  Technology 
risk  arises  because  many  systems  are  based  on  unproven  technologies. 
Project  development  teams  are  uncertain  about  how  the  technology  will 
perform  and  what  issues  might  arise  during  both  development  and 
operation  of  the  technology.  This  is  epistemic  uncertainty,  which  is 
resolved  by  gaining  knowledge  through  modeling,  analysis,  simulation, 
and  experimentation.  The  implication  for  this  paper  is  that  it  is  only  under 
uncertainty — in  this  case,  technical  uncertainty  due  to  complexity — that 
flexibility  has  value. 

Development  Lead-time 

The  system  acquisition  process  is  a  long  process,  with  the  average 
military  project  lasting  almost  10  years  (Charette,  2008).  The  high-level 
architectural  decisions  are  among  the  first  technical  decisions  made  in  the 
design  process.  The  dilemma  is  that  these  early  decisions  are  made  under 
the  greatest  amount  of  uncertainty.  The  implication  for  the  research  is  that 
architectural  decisions,  which  are  the  earliest  design  decisions,  have 
significant  impact.  If  the  architecture  is  designed  with  options  to  provide 
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flexibility,  then  it  is  possible  to  adapt  the  system  design  later  as 
operational  uncertainty  and  technical  uncertainty  are  resolved. 

3.  Development  Methods 

Systems  are  often  designed  and  built  to  provide  full  capabilities  in  the  first 
initial  delivery  of  the  system.  This  is  one  aspect  of  the  development 
process  contributing  to  very  long  development  times  for  some  programs. 
Acquisition  is  shifting  to  an  evolutionary  acquisition  strategy  that  fields  the 
initial  system  with  operationally  acceptable  capabilities  and  then  adds  new 
capabilities  in  subsequent  increments.  A  benefit  of  the  evolutionary 
approach  is  that  the  increments  need  not  be  done  if  the  operational 
environment  changes,  budgets  change,  or  technology  changes.  Another 
related  approach  to  acquiring  capabilities  is  via  systems  of  systems,  which 
are  managerial  independent  systems  that  interoperate  in  such  a  way  to 
provide  unique  and  useful  capabilities.  A  real  options  approach  to  systems 
engineering  is  best  matched  with  one  of  the  evolutionary  types  of  design 
processes  or  a  system-of-systems  engineering  approach.  A  traditional 
systems  engineering  process  is  not  amenable  to  a  real  options  approach 
because  if  all  of  the  capabilities  are  delivered  at  once  in  a  single  system 
without  consideration  of  future  upgrades,  then  there  is  no  role  for  options. 

4.  Opportunities  As  Well  As  Risks 

When  dealing  with  risk,  the  systems  engineering  and  project  management 
concentrate  on  the  downside  risk  and  take  steps  to  mitigate  or  avoid  the 
risk  or  reduce  the  consequences  of  the  risk  in  the  system  design.  What  is 
often  ignored  is  the  potential  upside  of  an  uncertain  event  that  the  system 
could  take  advantage  of.  A  real  options  approach  values  the  upside 
opportunities  as  well  as  the  downside  risks  associated  with  architectural 
decisions. 

5.  Changing  Technology 

In  some  cases,  such  as  information  technology  (IT),  it  is  important  to 
design  the  system  with  the  expectation  that  computing  capabilities  will 
grow  exponentially  and  the  computer  portions  of  the  system  will  be 
updated  in  a  shorter  cycle  than  other  components. 

Research  Goal 

This  research  is  targeted  to  acquisition  process  efficiency  and,  more 
specifically,  to  enhancing  Acquisition  decision-makers’  understanding  of  the 
relationship  between  system  architecture,  capabilities,  and  affordability.  The 
research  models  acquisition  as  a  sequential  decision  process  with  an  options 
framework  but  with  two  significant  distinctions:  First,  it  identifies  and  values  system 
architectural  options  available  in  the  system  design,  and  not  options  on  the  project, 
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and  second,  it  measures  capabilities  in  terms  of  mission  effectiveness  compatible 
with  how  defense  managers  think.  The  research  develops  the  theory,  builds  a 
computational  tool,  and  demonstrates  how  to  identify  and  value  architectural  options 
using  a  case  study  of  a  Navy  system.  The  research  contributes  to  the  early  trade 
studies  in  acquisition  through  the  definition  of  architectural  options  in  terms 
consistent  with  defense  acquisition  (capabilities  and  not  cash  flows)  and  a  theory  for 
how  program  managers  can  value  the  capabilities  that  those  options  provide.  The 
research  contributes  to  the  design  of  systems  that  can  be  affordably  developed  to 
deliver  value  over  their  entire  expected  service  life  via  a  spiral  acquisition  process. 
The  research  also  contributes  to  the  incorporation  of  flexibility  into  system 
architectures  through  the  concepts  derived  from  real  options. 

Research  Issues 

The  research  addresses  the  following  research  issues: 

1 .  how  to  define  options  in  system  architectures, 

2.  how  to  value  military  capabilities, 

3.  how  architectural  optionals  interact  with  one  another,  and 

4.  how  to  link  architectural  options  to  the  acquisition  decision  process  for 
affordability  analysis. 

The  following  sections  explain  how  the  paper  addresses  these  issues  in  our 
architectural  options  framework. 

Research  Approach 

This  research  project  is  premised  on  the  idea  that  delivering  affordable 
capabilities  starts  with  system  architecture  decisions  that  must  be  part  of  the  trade¬ 
off  decisions  between  performance,  cost,  and  schedule.  Affordability  must  consider 
the  entire  service  life  of  the  system.  It  is  probable — in  fact,  most  existing  systems 
have  illustrated — that  the  needs  and  subsequent  system  requirements  will  change 
over  the  life  of  the  system.  For  example,  the  IT  on  a  ship  will  become  obsolete  and 
require  replacement  in  order  to  maintain  value.  The  system  architecture  must  be 
designed  so  that  these,  and  other  less  obvious  changes,  can  be  accommodated  in 
the  future;  otherwise,  when  the  architecture  is  not  designed  for  these  changes,  the 
upgrades  become  very  costly. 

The  systems  engineering  process  and  the  acquisition  process  are  designed 
to  deliver  systems  that  meet  stated  requirements  at  a  particular  point  in  time.  Many 
designs  do  not  accommodate  for  changes  in  the  system  environment  in  terms  of 
threats,  changes  in  technology,  or  other  external  changes.  To  make  good  decisions 
justified  by  the  available  data,  the  program  manager  needs  to  do  the  following: 
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•  Link  architectural  options  and  decisions  to  needed  capabilities. 
Achieving  more  or  less  of  a  particular  capability  usually  implies  a 
change  in  the  system  architecture,  which  will  then  in  turn  affect  other 
system  capabilities,  including  desired  future  capabilities. 

•  Deal  with  the  uncertainty  in  the  underlying  data,  model  predictions,  and 
future  needs,  as  well  as  the  risk  that  emanates  from  those 
uncertainties. 

•  Value  capabilities  in  terms  of  mission  effectiveness  and  performance. 
Normally,  the  units  of  different  capabilities  will  be  incompatible  and 
there  will  be  more  than  a  few  that  must  be  simultaneously  traded  off, 
limiting  the  efficacy  of  simple  two-dimensional  graphs.  For  example,  in 
ship  design,  three  design  parameters — displacement,  endurance,  and 
speed — must  be  traded  off  simultaneously  along  with  other 
architecturally  significant  design  parameters. 

•  Account  for  how  present  decisions  will  affect  future  decisions.  The 
systems  engineering  community  knows  that  early  decisions  impact 
later  system  design  as  well  as  acquisition  decisions.  An  essential 
characteristic  of  any  decision  support  must  leave  flexibility — in  this 
paper’s  approach,  defined  as  architectural  options — that  will 
accommodate  future  decisions  affordably. 

It  is  under  uncertainty  that  architectural  options  have  value.  If  there  were  no 
uncertainty,  there  would  be  no  risk  and  no  need  for  architectural  options.  This 
research  subtask  investigates  the  nature  of  acquisition  uncertainty,  risk,  and 
capability  needs  and  then  develops  a  framework  to  model  and  link  them  together  in 
a  causal  network. 

Real  Options 

The  concept  of  real  options  is  taken  from  the  financial  options  on  which  they 
are  based.  Real  options  allow  the  holder  of  the  option  to  exercise  the  option  if 
conditions  are  favorable,  but  the  holder  is  not  obligated  to  exercise  the  option  if 
conditions  are  unfavorable  (Trigeorgis,  1995).  Consequently,  the  value  of  options  is 
that  they  allow  for  the  upside  potential  while  limiting  the  downside  risk.  Options  only 
have  value  in  the  face  of  uncertainty  and  when  that  uncertainty  is  expected  to  be 
resolved  before  all  of  the  investment  decisions  must  be  made.  This  situation  is  what 
is  faced  by  advanced  weapon  system  projects.  During  system  development  of 
advanced  weapon  systems,  the  uncertainty  is  due  to  technical  and  operational 
sources.  Project  success  is  only  apparent  after  the  project  starts  and  progresses.  A 
real  options  valuation  considers  the  fact  that  decisions  are  made  sequentially  and 
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that  the  decision-maker  will  use  all  available  information  at  the  time  the  decision  is 
made. 


Real  options  are  based  on  the  valuation  of  the  underlying  asset  whose  value 
is  modeled  as  a  stochastic  process.  In  finance,  the  underlying  asset  is  a  tradeable 
stock  and  the  stochastic  process  is  an  extension  of  the  historic  volatility  and  trend  of 
the  stock  using  Brownian  motion.  In  finance,  the  Black-Scholes  equation  is  used  to 
value  call  and  put  options  (Trigeorgis,  1995).  For  real  options,  selection  of  the 
underlying  asset  is  less  clear,  identifying  the  volatility  is  more  difficult,  and  there  are 
several  alternative  approaches  to  model  the  stochastic  process.  Formulating 
architectural  design  in  the  context  of  real  options  allows  valuation  of  architectural 
project  options  that  in  turn  allows  for  both  risk  reduction  and  the  possibility  of 
exploiting  upside  potential  if  it  should  arise. 

Real  options  give  the  right  but  not  a  symmetric  obligation  to  evolve  the 
system  and  enhance  the  opportunities  for  strategic  growth  by  making  future  follow- 
on  investments  (e.g.,  case  of  reuse,  exploring  new  markets,  expanding  the  range  of 
services  while  leaving  the  architecture  intact).  Since  flexibility  has  a  value  under 
uncertainty,  the  value  of  these  options  lies  in  the  enhanced  flexibility  to  cope  with 
uncertainty  (i.e.,  the  evolutionary  changes).  The  importance  of  the  real  options 
concept  cannot  be  overemphasized:  It  gives  the  architects/stakeholders  an  ability  to 
reason  about  a  crucial  but  previously  intangible  source  of  value  and  to  factor  the 
ability  of  an  architecture  to  adapt  into  the  tradeoff  analysis  and  acquisition  decision¬ 
making. 

Real  options  are  both  a  means  to  value  investments  as  well  as  a  means  to 
define  flexibility  in  system  deployment  (Trigeorgis,  2001).  Koenig  et  al.  (2009) 
discussed  the  high  level  of  uncertainty,  and  hence  risk,  associated  with  conventional 
engineering  economic  analysis  of  projects  that  have  long  operational  lives.  They 
suggested  that  the  DoD  environment  is  actually  rich  with  options,  but  until  now,  there 
has  been  no  quantitative  means  to  value  them  and  incorporate  them  into  the 
acquisition  decision  process.  In  fact,  quite  an  extensive  amount  of  research  has 
been  conducted  on  the  proposed  or  actual  use  of  real  options  with  project  planning 
and  acquisition. 

Real  options  are  better  at  valuing  investments  in  situations  where  the 
decision-maker  has  flexibility  to  make  changes  in  the  future  and  the  environment  is 
uncertain.  Traditional  approaches  to  valuing  investments  based  on  discounted  cash 
flows  are  inadequate  in  dealing  with  both  flexibility  and  uncertainty.  To  illustrate, 
consider  a  project  to  build  a  satellite.  The  investment  in  the  satellite  might  be 
unattractive  based  on  a  pure  net-present  value  analysis,  but  it  may  be  that  by 
launching  the  satellite,  the  organization  has  the  opportunity  to  add  additional 
valuable  capabilities  in  the  future.  These  possible  future  capabilities  are  not 
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considered  in  the  traditional  value  analysis,  and  it  is  these  possible  future 
capabilities,  called  options,  that  real  options  values.  In  uncertain  environments  when 
there  is  flexibility  to  make  subsequent  decisions,  traditional  valuation  approaches 
undervalue  flexibility  in  the  system. 

Architectural  Options  Framework 

This  section  describes  the  method  I  used  to  identify  system  architectural 
options  and  to  value  those  options.  Figure  1  shows  the  overall  concept  that  today’s 
capability  needs  will  evolve  over  time  to  future  capability  needs.  Architectural  options 
are  needed  to  enable  fulfillment  of  these  future  capability  needs.  Incorporating  them 
into  the  architecture  today  requires  understanding  their  value — hence,  real  options. 


Figure  1.  Architectural  Options  and  Relationship  to  Capability  Needs 

System  architecture  is  the  representation  of  the  structure  of  a  system 
embodied  by  its  elements,  the  logical  and  physical  relationships  between  the 
elements,  their  relationships  with  the  environment,  and  the  principles  or  concept 
guiding  the  system's  design  and  evolution  over  time.  The  types  of  elements  and 
relationships  in  an  architecture  depend  on  the  architectural  view  of  operational, 
functional,  or  physical.  A  system  architecture  is  divided  into  three  main  views — 
operational,  functional,  and  physical  architectures — with  mappings  showing  how 
elements  in  one  view  are  related  to  elements  in  the  other  views.  Collectively,  the 
three  views  provide  a  holistic  model  of  how  the  system  fulfills  its  mission.  This  paper 
considers  all  three  architectural  views  in  this  research.  The  views  are  all  included  in 
Department  of  Defense  Architectural  Framework. 

ACQUISITION  RESEARCH  PROGRAM 

GRADUATE  SCHOOL  OF  BUSINESS  &  PUBLIC  POLICY  -  8  - 

NAVAL  POSTGRADUATE  SCHOOL 


The  development  of  a  system  architecture  is  driven  by  a  design  concept  that 
gives  form  to  ideas  about  how  a  system’s  functions  and  behaviors  maximize 
stakeholder  value.  The  architect  must  balance  the  many  competing  needs  and 
objectives  present  in  modern,  complex  system  design  projects.  A  design  concept  is 
a  central  part  of  an  architecture  because  it  describes  how  the  system's  form 
embodies  working  principles  and  how  functions  and  behaviors  are  mapped  to 
physical  components.  The  concept  guides  future  design  decisions.  Many  acquisition 
professionals  are  familiar  with  operational  concepts  as  described  in  the  concept  of 
operations  (CONORS)  document.  Likewise,  design  concepts  underlie  the  functioning 
and  physical  structure  of  the  system.  Oftentimes,  the  architecture  informally  or 
inexplicitly  defines  the  concept. 

The  architectural  options  approach  involves  the  following  steps: 

1 .  identify  sources  of  uncertainty, 

2.  define  measures  for  the  capabilities, 

3.  model  uncertainty  using  scenarios, 

4.  partition  the  system  architecture  into  modules, 

5.  define  architectural  options  in  the  architecture, 

6.  value  options,  and 

7.  present  the  valuation  to  the  decision-maker. 

These  steps  are  described  in  the  following  subsections. 

Classification  of  Program  Uncertainty,  Risk,  and  Capability 
Needs 

Uncertainty  is  the  state  of  not  knowing  something  exactly,  and  this  is  a 
pervasive  state  in  the  design  of  systems.  Uncertainty  in  a  system  can  arise  in  the 
operational  environment,  technology  environment,  and  the  acquisition  process. 
Uncertainty  can  be  classified  as  either  epistemic  uncertainty  or  aleatory  uncertainty. 
Epistemic  uncertainty  is  due  to  our  incomplete  knowledge  of  the  system,  threats,  or 
operational  environment  and  is  especially  prevalent  in  the  early  stages  of  the  system 
design  process.  Through  research  and  development,  these  uncertainties  are 
systematically  removed  during  the  acquisition  process.  Aleatory  uncertainty  is  due  to 
the  inherent  variability  of  the  system  parameters,  system  input,  or  system 
environment.  Aleatory  uncertainty  is  the  irreducible  uncertainty;  it  cannot  be 
removed  and  is  quantified  in  a  statistical  manner. 

The  uncertainty  most  relevant  to  architectural  options  is  operational 
uncertainty  and  technical  uncertainty.  Systems  are  acquired  with  very  long  expected 
operational  lives.  The  USS  Gerald  R.  Ford  (CVN-78)  aircraft  carrier  is  being 
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acquired  with  the  intention  of  beginning  its  operational  phase  in  2016.  The  ship  is 
designed  to  operate  for  50  years — the  planned  disposal  date  is  2066.  Given  this  long 
operational  life,  it  is  impossible  to  accurately  forecast  how  naval  warfare  and  the 
capability  needs  of  the  aircraft  carrier  will  change  during  these  years. 

Systems  are  exposed  to  uncertainty  in  their  technical  environment  in  that  the 
technology  will  change  and  technological  opportunities  will  emerge  over  the 
system’s  operational  life.  Technology  advances  in  both  a  predictable,  evolutionary 
manner  as  well  as  in  a  disruptive  manner.  Technology  evolution  leads  to 
obsolescence  of  technology  and  the  need  to  periodically  update  the  technology.  The 
simplest  obsolescence  is  when  the  technology  can  be  replaced  with  a  newer 
technology  that  has  the  same  interface.  Obsolescence  that  involves  interface 
changes  is  more  difficult  to  deal  with,  and  the  most  difficult  obsolescence  to  handle 
is  if  the  functionality  changes  or  there  is  a  disruptive  technology  shift  that  leads  to  a 
new  design  concept  incompatible  with  the  system’s  architecture.  A  technology  can 
become  functionally  obsolete  because  it  is  subsumed  by  another  technology  or  a 
different  design  concept. 

Systems  are  exposed  to  uncertainty  in  their  operational  environment.  The 
operational  environment  is  characterized  by  the  missions  that  a  system  is  designed 
for,  the  capabilities  it  needs  to  fulfill  those  missions,  and  the  nature  of  the  threats  it 
will  encounter. 

To  enable  this  strategy,  the  system  architecture  must  be  designed  to  support 
the  incremental  addition  of  capabilities.  Sources  of  uncertainty  are  changes  to  the 
operational  environment,  to  the  funding  availability,  and  to  the  technical 
environment.  Changes  to  the  operational  environment  flow  down  to  the  system  and 
change  system  requirements. 

Some  uncertainty  can  be  resolved,  such  as  with  technology  evolution,  which 
might  be  predicted  to  continue  following  Moore’s  Law  in  the  near  to  mid-term  future. 
In  this  case,  the  uncertainty  is  not  in  technology  evolution  but  in  the  rate  of  growth 
and  the  implications  of  that  growth. 

Measuring  Capabilities 

A  capability  is  defined  as  the  ability  to  achieve  a  desired  effect  under 
specified  standards  and  conditions  through  combinations  of  means  and  ways  across 
DOTMLPF  to  perform  a  set  of  tasks  to  execute  a  specified  course  of  action  (JCIDS). 
The  term  ways  and  means  refers  to  the  non-materiel  components  and  the  materiel 
components  of  the  capability,  respectively.  A  capability  is  essentially  a  high-level 
operational  requirement  expressed  in  language  that  the  stakeholder  understands.  A 
measure  of  effectiveness  (MOE)  is  a  measure  that  corresponds  to  the  delivery  of  a 
capability  in  the  system’s  expected  environment.  MOEs  are  defined  from  the 
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stakeholder's  perspective,  specifically  the  acquirer.  A  good  MOE  is  linked  to  the 
desired  end  state,  has  a  strong  relationship  between  cause  and  effect,  and  is 
observable  and  quantifiable.  A  MOE  is  defined  without  reference  to  the  design 
solution  and  should  in  theory  be  a  useful  measure  regardless  of  what  technology, 
design,  or  process  is  used  to  meet  the  capability  needs. 

A  measure  of  performance  (MOP)  is  a  measure  of  the  performance  of  a 
system  function.  A  MOP  is  defined  from  the  technical  viewpoint  of  designing  a 
system  that  will  fulfill  the  mission  as  characterized  by  the  MOEs.  Since  a  capability  is 
fulfilled  by  one  or  more  system  functions,  a  MOP  that  measures  the  performance  of 
a  function  will  consequently  map  to  a  capability  via  the  function. 

Architectural  Options 

The  first  research  issue,  architectural  options,  is  part  of  the  system  design 
process  and  requires  awareness  of  the  design  team  to  think  about  options  as  well  as 
creativity  to  design  system  architectures  around  those  options.  The  need  for 
architectural  options  in  systems  is  to  provide  flexibility  for  the  system  in  adapting  to 
uncertainty  in  the  operational  and  technical  environment.  As  discussed  in  the 
Literature  Review  section,  there  is  little  work  in  identifying  options  in  the  architecture 
as  opposed  to  the  more  common  definition  of  options  on  the  project. 

The  architectural  options  are  all  part  of  the  same  system  and  consequently 
will  be  interdependent — in  essence,  a  system  describes  a  portfolio  of  options.  The 
interdependence  must  be  included  in  the  model  since  changes  in  any  one  option  will 
affect  others. 

The  system  architectural  options  must  be  linked  to  the  capabilities  they 
provide  and  incorporated  into  the  acquisition  decision  process.  Linking  options  to 
capabilities  entails  understanding  how  the  architectural  options  contribute  to  system 
performance  and  measuring  them  in  a  way  that  they  can  be  included  in  the  trade-off 
analysis  conducted  by  the  program  manager  and  others  for  affordability  analysis. 
Figure  2  shows  the  relationship  between  the  sources  of  uncertainty,  what  actions 
could  be  taken  to  deal  with  the  uncertainty,  and  how  architectural  options  enable 
those  actions.  For  example,  future  operations  might  require  greater  use  of  special 
operations  forces,  a  source  of  operational  uncertainty.  A  capability  gap  may  be  the 
Navy’s  ability  to  deploy  these  forces.  An  action  could  be  the  development  of  a 
special  operations  module  on  the  Littoral  Combat  Ship  (LCS)  —  an  “add  component” 
action.  The  add  component  action  is  enabled  by  architectural  options  that  include 
the  infrastructure  support,  weight/space  support,  open  interfaces,  and  ability  to  form 
modules. 
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Figure  2.  Relationship  Between  Uncertainty  and  Architecture  Options 
Clustering  into  Modules 

Modularity  and  open  architecture  concepts  are  important  enablers  to  a  real 
options  approach  to  system  architecture.  Architecture  modularity  is  achieved  by 
partitioning  the  system  into  self-contained  subsystems  that  deliver  complete 
functions  independent  of  other  subsystems.  The  interfaces  between  subsystems 
should  use  open  standards  and  be  transparent  to  the  greatest  extent  possible. 
Another  important  consideration  is  the  expected  technical  operational  use  of  the 
subsystem.  Computer  and  IT  subsystems  tend  to  become  obsolete  much  faster  than 
most  hardware-oriented  subsystems.  Separating  these  subsystems  into  self- 
contained  subsystems  or  designing  them  for  easy  updating  of  software  increases  the 
modularity  of  the  system. 

Mission  modules  apply  the  modularity  concept  to  the  operational  architecture 
because  they  provide  flexibility  to  respond  to  different  missions.  The  best  example  of 
mission  modularity  is  the  LCS,  which  has  mission  modules  planned  for 
antisubmarine  warfare,  surface  warfare,  and  mine  warfare. 

A  module  has  high  internal  cohesion  and  low  coupling  with  other  elements  in 
the  system.  Ulrich  and  Eppinger  (2011)  defined  three  types  of  modularity:  slot 
modular,  bus  modular,  and  sectional  modular.  Slot-modular  components  are  defined 
with  unique  interfaces.  Bus-modular  components  are  defined  with  a  common 
interface.  Sectional-modular  components  can  be  attached  to  other  modules  by 
means  of  a  standard  interface. 

Interdependence 

A  module  has  low  coupling  with  other  modules  and  high  internal  cohesion. 
Cohesion  and  coupling  are  two  measures  of  the  interactions  between  components  in 
a  system.  Cohesion  is  a  measure  of  the  degree  to  which  components  within  a 
subsystem  interact  with  each  other  to  perform  a  single  function  or  small  set  of 
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related  functions.  Coupling  is  the  degree  of  the  interaction  between  subsystems.  To 
paraphrase,  cohesion  is  within  a  single  subsystem  and  coupling  is  between 
subsystems.  This  discussion  uses  the  generic  term  interactions',  however,  it  is 
possible  to  define  cohesion  with  respect  to  other  characteristics  such  as  engineering 
knowledge  domains,  type  of  material  or  manufacturing  process,  or  the  functions  that 
the  components  perform.  For  example,  the  hydraulic  subsystem  in  an  airplane  is 
defined  to  be  cohesive  in  terms  of  the  domain  knowledge  required  to  design  and 
develop  the  hydraulics. 

A  heuristic  is  a  rule  of  thumb  that,  in  the  context  of  architecture,  describes  a 
best  practice  that  creates  a  modular  and  flexible  architecture  via  architectural 
options.  The  heuristic  to  maximize  the  cohesion  of  subsystems  and  to  minimize  the 
coupling  between  subsystems  has  proven  useful  again  and  again.  The  reasons  for 
this  heuristic  are  to  make  an  architecture  that  is  more  easily  understood;  to  make 
partitioning  the  system  into  subsystems  easier;  to  minimize  the  number  of  interfaces 
between  subsystems;  and  to  make  changing,  maintenance,  and  supportability  of  the 
system  easier.  Each  of  these  objectives  is  discussed  in  this  section.  First,  a  system 
that  has  high  cohesion  within  subsystems  and  low  coupling  between  them  is  easier 
to  understand  because  it  has  fewer  interactions  at  the  system  level.  The  interactions 
are  mostly  within  the  subsystem  level,  which  is  hidden  in  the  architecture  level.  The 
low  coupling  between  subsystems  means  that  there  are  fewer  interfaces  between 
subsystems.  This  makes  the  project  easier  to  manage  since  interfaces  are 
negotiated  and  then  become  configuration  control  items  via  the  interface  control 
document.  Minimizing  coupling  works  because  the  interactions  between  subsystems 
are  generally  more  difficult  to  manage  and  control  due  to  how  most  systems 
engineering  projects  are  performed.  In  general,  each  subsystem  is  assigned  to  a 
subteam —  a  small  group  that  is  more  easily  managed  by  the  project  manager — for 
completion.  All  of  the  interactions  inside  of  a  subsystem  are  within  the  control  of  the 
subteam.  The  interactions  between  subsystems  will  involve  two  or  more  subteams. 
The  coordination  of  the  work  of  these  subteams  is  more  difficult  and  requires  greater 
effort  and  negotiation.  Consequently,  by  minimizing  coupling,  you  minimize  the  need 
for  coordination  between  subteams. 

When  subsystems  are  loosely  coupled,  one  of  the  subsystems  can  be 
changed  without  or  with  only  minimal  need  to  change  the  other  subsystem.  In  other 
words,  the  subsystems  are  highly  independent.  Changes  to  one  do  not  necessarily 
infer  changes  to  the  other.  In  system  development,  this  independence  between 
subsystems  is  good  because  it  reduces  the  need  for  coordination  between  the 
subteams  developing  each  subsystem.  This  property  is  also  beneficial  to  upgrades 
of  the  system,  because  one  subsystem  could  be  upgraded  without  necessitating 
upgrades  to  the  other  subsystem.  In  general,  it  is  found  that  coupling  is  detrimental 
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to  system  development  because  it  prevents  making  changes  to  components 
independent  of  the  whole. 

Coupling  between  two  components  is  due  to  the  interaction  between  the 
components,  classified  per  the  types  shown  in  Table  1.  The  interaction  types  are 
used  to  populate  a  design  structure  matrix  (DSM).  The  DSM  shows  each  component 
in  what  is  essentially  an  N2  matrix  and  the  interactions  between  them  as  either  a  0 
or  a  1. 


Table  1.  Interaction  Types 


No  interaction 


Physical  interaction 
(static) 


Energy  flow 


Material  flow 


Information  flow 


Computer  algorithms  are  needed  to  help  identify  potential  modules  because  the  size 
and  complexity  of  system  architectures  preclude  a  manual  approach.  This  paper 
adopts  a  clustering  algorithm  from  Thebeau  (2001),  who  defined  a  cost  for  each 
module  based  on  interactions  with  penalties,  adjustable  by  the  user,  for  cluster  size 
as  well  as  a  few  other  parameters  to  control  the  algorithm.  The  algorithm  uses  a 
bidding  process  with  hill  climbing  to  search  for  an  optimal  solution.  The  top  graph  of 
Figure  3  shows  one  of  the  DSMs  evaluated  in  this  paper;  the  bottom  graph  shows 
how  the  clustering  algorithm  formed  modules.  A  good  modularization  has  most  of 
the  interactions  inside  a  module  and  very  few  interactions  between  modules.  The 
results  for  the  simple  case  show  only  ten  interactions  outside  and  between  modules. 

In  the  practice  of  forming  modules,  the  algorithm  is  executed  iteratively  with 
the  user  changing  parameters  or  the  DSM,  re-executing  the  algorithm,  and  repeating 
the  cycle  until  a  satisfactory  clustering  of  modules  is  formed.  The  point  of  the 
algorithm  is  to  speed  up  the  generation  of  alternative  architecture  modularization 
concepts,  but  the  algorithm  does  not  necessarily  automatically  generate  the 
modularization  that  is  eventually  used. 
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Figure  3.  The  Initial  Design  Structure  Matrix  and  the  System  Clustered  into 

Modules 

Architecture  Heuristics 

Table  2  shows  the  main  architecture  heuristics.  These  heuristics  are  used  to 
design  system  architectures  to  create  architectural  options. 
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_ Table  2.  List  of  Architecture  Heuristics _ 

_ Heuristics _ 

Architecture  models  to  standardize  data,  processes,  and  structure 

_ Function  partitioning _ 

_ Partition  hardware  and  software _ 

_ Partition  high-risk  technologies _ 

_ Specialization  versus  generalization _ 

Interfaces  used  industry-supported  standards 

The  interface  between  modules  is  important;  Table  3  shows  the  general  types 
of  interfaces.  The  architectural  options  require  the  interfaces  between  the  modular 
subsystems  to  be  defined  appropriately. 


Table  3.  Interface  Types 


Interface  Type 

Description 

Connector 

Facilitates  interaction  of  energy,  material,  or 
information  flows 

Isolator 

Inhibits  interaction  of  energy,  material,  or 
information  flows 

Converters 

Alters  the  flow  in  the  interaction 

Scenarios 

A  scenario  is  a  possible  outcome,  usually  operational  in  nature,  and  is 
modeled  as  a  node  in  a  decision  tree  (see  Figure  4).  Scenario  modeling  is  a 
standard  approach  in  systems  engineering. 
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Figure  4.  Scenarios  in  a  Decision  Tree 


Valuation  of  Options 

The  valuation  of  architectural  options  is  performed  with  a  decision-tree 
structure  because  the  uncertainty  is  defined  by  the  future  operational  and  technical 
scenarios.  The  decision  tree  is  represented  mathematically  using  set  theory.  Let  t 
denote  a  time  period  in  the  set  1  ...  T.  In  each  time  period,  the  decision-maker 
makes  a  decision  in  whether  to  invest  in  an  option.  Let  denote  the  execution  of 
option  i  in  time  period  t. 

The  objective  is  to  maximize  the  MOP,  which  varies  with  time  t,  the 
operational  scenario  k  that  the  system  encounters,  and  which  options  i  are  active  in 
the  system.  The  real  options  model  assumes  that  there  is  a  fixed  lower-level 
performance  denoted  by  fi  and  a  variable  component  denoted  by  The  objective 
function  is 


T  I  K 

MAX  MOP  =  111  fi  (^  ) 

t=l  i=l  k=l 

The  decision-maker  evaluates  the  values  in  the  decision  tree  for  all  terminal 
nodes  and  then  works  backward  until  reaching  the  root  node.  The  value  at  each 
node  is  represented  with  a  value  vector  vj  that  stores  the  accumulated  benefits  and 
costs  from  the  downstream  nodes. 
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Presentation  of  Results 


The  decision  tree  valuation  results  are  best  presented  as  architectural  trade¬ 
off  curves  showing  the  capabilities  measured  by  MOEs/MOPs  and  the  cost.  See 
Figure  5. 


Figure  5.  Notional  Architecture  Trade-Off  Curve 


Publications  and  Dissemination  of  Results 

A  paper  will  be  published  at  the  2014  Acquisition  Research  Symposium  to 
illustrate  the  method.  Additionally,  a  journal  article  is  in  preparation  on  the  valuation 
of  real  options  for  the  phased  acquisition  of  system  capabilities. 

Related  Research  Efforts 

LCDR  Heather  Skowron,  a  student  at  the  Naval  Postgraduate  School  (NPS), 
is  doing  her  master’s  thesis  to  specify  a  phased  plan  for  the  Coast  Guard  to  develop 
and  deploy  a  manpower  determination  system,  which  is  a  workflow  system  for  the 
Coast  Guard  to  analyze  the  workload  requirements  for  ships  and  determine  the  type 
and  number  of  crew.  Skowron  is  designing  a  modular  system  architecture  and 
mapping  it  to  a  schedule  that  will  deliver  capabilities  in  an  evolutionary  manner  every 
six  months.  The  architecture  is  designed  to  utilize  commercial  standards  to  preserve 
openness,  and  it  allows  Coast  Guard  decision-makers  options  on  whether  to 
implement  certain  system  elements  depending  on  their  valuation  of  the  capabilities 
provided.  Skowron  is  expected  to  complete  her  thesis  by  May  2014.  A  second  NPS 
student,  LCDR  Kara  Lavin,  is  expected  to  continue  this  line  of  research  for  the  Coast 
Guard  when  she  does  her  thesis  later  in  2014. 

Progam  Executive  Office  Integrated  Warfare  Systems  1.0  is  interested  in 
combat  system  flexibility  and  system  modularity.  It  presented  this  research  topic 


-  18- 


ACQUISITION  RESEARCH  PROGRAM 

GRADUATE  SCHOOL  OF  BUSINESS  &  PUBLIC  POLICY 

NAVAL  POSTGRADUATE  SCHOOL 


during  the  2014  Naval  Research  Requirements  Fair.  I  spoke  to  the  research  sponsor 
and  plan  to  submit  a  proposal  to  do  this  research,  which  will  build  upon  the  research 
conducted  in  this  project. 

Related  Work 

This  research  seeks  to  develop  a  model  and  method  to  use  real  options  to 
value  system  architectural  options  and  is  consequently  related  to  research  in  system 
flexibility  and  in  real  options.  Flexibility  has  long  been  desired  in  the  design  of 
systems  in  order  to  deal  with  anticipated  uncertainty  in  the  system's  development 
and  operational  lifetime  (Giachetti,  Martinez,  Saenz,  &  Chen,  2003;  Ross,  Rhodes,  & 
Hastings,  2008).  In  the  past  decade,  the  theory  of  real  options  has  increasingly  been 
seen  as  a  means  to  define  and  value  flexible  investment  decisions  in  a  project  (Mun, 
2006;  Trigeorgis,  1996).  Real  options,  inspired  by  the  use  of  financial  options,  allow 
the  option  holder  to  exercise  the  option  if  conditions  are  favorable,  but  the  holder  is 
not  obligated  to  exercise  the  option  if  conditions  are  unfavorable;  the  overall  result  of 
this  process  allows  for  upside  potential  and  limiting  the  downside  risk  (Trigeorgis, 
1996).  These  options  have  value  because  of  the  decision  flexibility  they  provide 
(Brosch,  2008).  To  date,  almost  all  applications  of  real  options  have  been  what  is 
termed  options  on  projects  (Wang  &  de  Neufville,  2006).  Typical  examples  include 
the  following:  Giachetti  (2012)  described  a  scenario  where  real  options  to  delay, 
scale  up,  scale  down,  or  abandon  the  project  are  applied  to  enterprise  system 
projects  in  the  DoD.  Pennock,  Rouse,  and  Kollar  (2007)  applied  the  Black-Scholes 
equation  to  ship  acquisition.  Angelis,  Ford,  and  Dillard  (2013)  described  a  case 
study  of  applying  real  options  to  the  Army’s  acquisition  of  the  Javelin  anti-tank 
weapon  system  in  which  they  considered  three  alternatives  to  provide  the  capability. 
Real  options  on  projects  are  available  in  all  projects  and  have  been  applied  in  the  IT 
industry,  in  the  oil  and  gas  exploration  industry,  and  to  research  and  development 
portfolios. 

What  is  far  less  common  is  the  identification  and  application  of  options  in  the 
system  architecture  design  itself.  Wang  and  Neufville  (2006)  provided  an  example  of 
a  real  option  designed  into  a  system,  where  they  described  the  design  of  a  bridge 
across  the  Tagus  River  in  Portugal.  The  bridge  was  being  designed  for  automobile 
traffic,  yet  the  government  realized  that  in  the  future,  they  might  want  to  also  have 
trains  cross  the  Tagus  River.  Building  two  separate  bridges,  one  for  each  mode  of 
transportation,  is  more  expensive  than  if  a  single  bridge  were  designed  to  handle 
both.  Yet,  whether  rail  transport  would  ever  be  realized  was  uncertain.  The 
engineers  proposed  a  real  option  designed  into  the  bridge  of  building  supports 
capable  of  supporting  two  decks:  one  for  automobile  traffic  and  a  second  for  rail 
traffic.  The  bridge  would  initially  be  built  exclusively  for  automobile  traffic,  but  the 
beefier  supports  created  the  system  architectural  option  for  adding  the  second  deck 
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for  rail  traffic.  Real  options  valuation  lets  the  decision-makers  analyze  whether  the 
additional  investment  is  warranted,  and  in  this  case,  it  was.  This  example  illustrates 
a  significant  difference  between  real  options  on  projects  versus  in  projects.  To  obtain 
real  options  in  projects,  the  systems  engineers  must  identify  future  uncertainties  and 
design  the  options  into  the  system  architecture  so  that  the  option  for  realizing  that 
flexibility  is  available  in  the  future.  The  research  in  identifying  and  designing  options 
into  system  architecture  is  far  less  realized  than  the  traditional  stream  of  research 
into  real  options  (Engle  &  Browning,  2008).  Burrman,  Zhang,  and  Babovic  (2009) 
examined  real  options  and  applied  them  to  the  architecture  of  a  maritime  domain 
protection  system  in  which  the  options  are  defined  in  terms  of  dollar  value  for  costs 
and  benefits.  Engel  and  Browning  (2008)  examined  how  to  define  architectural 
options  and  show  a  valuation  scheme  of  mapping  the  standard  Black-Scholes 
equation  to  terminology  for  modular  architectures.  Mohr  (2009)  used  real  options  to 
value  the  flexibility  of  modular  cabins  able  to  accommodate  changing  passenger 
demands.  Silver  and  de  Week  (2007)  used  a  graph  to  model  the  switching  cost 
between  different  architectural  configurations.  Their  analysis  used  cost.  What  Silver 
and  de  Week’s  research  has  in  common  is  that  the  value  of  the  option  is  entirely  in 
financial  terms. 

An  issue  in  the  defense  sector  is  how  to  value  options  in  terms  of  capabilities. 
Mun  and  Housel  (2010)  presented  a  collection  of  tools  based  on  real  options  that 
uses  the  concept  of  knowledge  value  added  (KVA)  as  a  surrogate  for  the  benefits 
derived  from  an  option.  The  KVA  approach  addressed  the  contradiction  of  using 
money  to  value  options  for  the  military.  Ford,  Housel,  and  Dillard  (2010)  used  KVA  in 
conjunction  with  simulation  models  for  the  analysis  of  alternative  unmanned  aerial 
vehicles,  and  they  presented  data  where  a  Predator  has  a  KVA  of  943,  versus  a 
KVA  of  1222  for  Sky  Warrior.  The  question  is,  what  do  these  unitless  KVA  values 
mean  to  an  acquisition  program  manager?  The  unitless  KVA  measures  have  no 
correspondence  to  how  program  managers,  systems  engineers,  and  other 
stakeholders  think  about  the  system's  performance  and  capabilities,  which  severely 
limits  their  applicability.  The  paper  determines  that  there  is  a  need  for  valuation  in 
terms  already  used  within  the  acquisition  community. 

The  majority  of  work  on  real  options  deals  with  options  on  projects,  such  as 
whether  to  delay,  expand,  contract,  or  make  similar  changes  to  the  project 
dimensions.  A  few  researchers  have  examined  real  options  on  the  architecture, 
which  are  options  designed  into  the  architecture  by  engineers.  Traditional  options 
theory  values  the  costs  and  benefits  of  options  in  terms  of  dollar  values.  However, 
military  capabilities  are  measured  in  terms  of  MOEs  and  performance.  A  model  of 
architectural  options  that  deliver  military  capabilities  needs  to  utilize  units  that  have 
meaning  to  the  stakeholders.  Military  stakeholders  need  to  understand  the  trade-off 
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between  the  architectural  options  and  how  it  affects  capabilities,  as  opposed  to  the 
industry  practice  of  valuing  options  in  strictly  dollar  terms. 

In  summary,  the  research  on  architectural  options  is  underdeveloped,  and 
incorporation  of  non-financial  measures  of  the  value  of  options  has  not  been  widely 
examined.  Both  these  issues  are  critical  to  a  more  efficient  acquisition  process  that 
emphasizes  affordability. 

Summary 

The  research  project  developed  a  method  to  identify  and  value  architectural 
options.  The  approach  is  to  identify  uncertainty  that  the  system  will  face,  model  it  in 
a  decision  tree  via  scenarios,  identify  a  means  to  measure  system  capabilities, 
define  system  modules  and  architectural  options,  apply  real  options  to  value  the 
options,  and  then  present  the  results  to  a  decision-maker  in  the  form  of  architecture 
trade-off  curves.  The  intent  of  the  research  is  to  aid  a  decision-maker  in  identifying 
architectural  options  and  defending  their  inclusion  in  the  architectural  design  via  the 
valuation. 
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